Transaction resources for stateless message protocol

ABSTRACT

A communications device, such as an Internet-of-Things device, includes an entity resource to originate or consume data, and core resources to facilitate stateless messaging with a remote device, with the messaging being associated with the entity resource. Transaction resources are provided to manage a transaction with the remote device. The transaction includes a sequence of messages associated with the entity resource. The transaction resources include a transaction state machine to represent a current intra-transactional ephemeral state from among a plurality of intra-transactional ephemeral states representing progression of the transaction, a commit handler to institute a persistent state change related to the entity resource in response to a successful completion of the transaction, and a transaction communicator to conduct intra-transaction communications via the core resources directed to corresponding transactional resources of the remote device.

TECHNICAL FIELD

This application is a continuation of U.S. patent application Ser. No.16/473,597, filed Jun. 25, 2019, which is a U.S. National StageApplication Under 35 U.S.C. 371 from International Application No.PCT/US2017/014915, filed Jan. 25, 2017, published as WO 2018/140006, allof which are incorporated herein by reference in their entirety.

TECHNICAL FIELD

Embodiments described herein generally relate to data communicationsand, more particularly, to facilitating low-latency transactions incommunication systems utilizing stateless messaging protocols.

BACKGROUND

The Internet of Things (IoT) is the networking of physical objects, suchas sensors and actuators, vehicles, building automation systems,information devices, and other items, which are embedded withelectronics, software, and network connectivity that enables theseobjects to collect and exchange data. IoT as a new communications andinteraction paradigm is rapidly developing to offer many new and usefulfeatures in applications such as smart home, smart city, industrialcontrol, and smart transportation.

IoTivity is an IoT framework that implements Open ConnectivityFoundation (OCF) standards to ensure interoperability of IoT devices.IoTivity features a declarative model for describing resourceinteractions among IoT devices. It is well-suited for using arepresentational state transfer (RESTful) approach to distributedcomputing. RESTful behavior allows servers, or devices responding tomessages, to remain stateless as a strategy for improved scalability.However, some interactions involve maintaining the protocol state, suchas provisioning devices into a network, establishing or adjustingoperational settings or polices, exchanging credentials, and the like.An incomplete configuration leaves the device in an undefinedoperational state where either the configuration is to be completed, orrolled back to a previous state.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings, which are not necessarily drawn to scale, like numeralsmay describe similar components in different views. Like numerals havingdifferent letter suffixes may represent different instances of similarcomponents. Some embodiments are illustrated by way of example, and notlimitation, in the figures of the accompanying drawings.

FIG. 1 is a high-level diagram illustrating examples of various types ofcomputing platforms, including IoT platforms, on which aspects of thesubject matter may be implemented according to some embodiments.

FIG. 2 is a block diagram illustrating a computer system in the exampleform of a general-purpose machine.

FIG. 3A is a diagram illustrating an exemplary hardware and softwarearchitecture of a computing device such as the one depicted in FIG. 2,in which various interfaces between hardware components and softwarecomponents are shown.

FIG. 3B is a block diagram illustrating examples of processing devicesthat may be implemented on a computing device according to someembodiments.

FIG. 3C is a block diagram illustrating example components of aprocessing device, according to various embodiments.

FIG. 4A is a diagram illustrating an example IoT device architectureaccording to some embodiments, at a high level of abstraction.

FIG. 4B illustrates an example set of components that are included intransaction resources according to some embodiments.

FIG. 5 is a diagram illustrating an example state graph data structuresaccording to an embodiment.

FIG. 6 is a diagram illustrating a transaction message collectionaccording to an example.

FIG. 7 is a block diagram illustrating the transaction resources of anIoT device according to an embodiment utilizing an IoT framework such asOCF/IoTivity.

FIG. 8 is a flow diagram illustrating the progress of an exampletransaction between two IoT devices, each utilizing its respectivetransaction resources.

FIG. 9 is a system architecture and data flow diagram illustratingexample interactivity between a pair of IoT devices utilizing principlesof some embodiments.

DETAILED DESCRIPTION

Aspects of the embodiments are directed to communications betweendevices using stateless protocols. In general, a stateless protocol is acommunications protocol that treats each request as an independenttransaction that is unrelated to any previous request so that thecommunication is composed of independent pairs of request and response.A stateless protocol does not require the server, or responsive entity,to retain session information or status about each communicationspartner for the duration of multiple requests. For ease of illustration,various examples are described herein in the context of IoTivityprotocols, and RESTful architecture. However, it will be understood thatprinciples of the embodiments may be applicable in various othercontexts or applications, particularly those utilizing a statelesscommunications paradigm.

According to some aspects of the embodiments, each transaction, which inthe present context, refers to a series of exchanged messages betweenentities to achieve a particular result, may involve a sequence ofmessages to be communicated. Accordingly, different states may bemaintained by an initiating entity, responsive entity, or both. Exampleuse cases involving sequences of operations include, without limitation,key exchange protocols, provisioning, setup and manageability, key andcertificate management, access policy provisioning, on-boarding, and thelike.

In a conventional RESTful paradigm, multi-state transactions invitevarious challenges. For one, there is no effective coordination betweeneach initiator and responder. There is no guarantee the protocol willprogress as intended, and there is no provision for data cleanup if theprotocol aborts.

To facilitate management of such transactions, a transactional resourceis instantiated for each transaction that coordinates multiple RESTfulmessage exchanges. The transaction resource is discoverable by otherdevices; hence they may interact with the resource—effectively invokingthe transaction.

In some examples, the various message exchanges involved in a giventransaction are modeled using a resource property state machine thatspecifies the sequence in which the various RESTful messages may beapplied. Message contents or protocol data units (PDUs) are defined asresources such that RESTful commands (e.g. GET, PUT, POST, etc.) may beapplied to effect the information exchange. By applying OBSERVE over thetransaction resource's state property it is possible for bothcommunicating entities to determine when it is appropriate to continueto the next step (even if connection is lost/re-established) or toperform cleanup if the transaction aborts or commits, for example.

Advantageously, the use of transaction resources enable IoT applicationsto implement transactional interaction protocols such as deviceprovisioning, key exchange, multi-phase commit and the like, using adeclarative object model (such as OCF/IoTivity).

In various examples, the transaction resource allows an IoT frameworklayer to optimize message delivery using any available messagingmethodology (e.g. pub/sub, req/resp, event/notify etc.) using MQTelemetry Transport (MQTT), Extensible Messaging and Presence Protocol(XMPP), Extensible Markup Language (XML), Constrained ApplicationProtocol (COAP), Data Distribution Service (DDS) and others may be usedby the framework layer.

FIG. 1 is a high-level diagram illustrating some examples of varioustypes of computing platforms that may be incorporated in IoT devices.The computing platforms include servers or personal computers, such asPC 102, laptop 104, smartphone/tablet 106, and the like. Other types ofinformation devices, such as networking appliance 108, which representsa switch, router, access point, etc., are computing platforms that arealso contemplated. Industrial equipment 110, such as control systems,automated tooling, motor/robotics controls, programmable logiccontrollers, are also types of computing platforms on which aspects ofthe embodiments may be implemented. Computing platforms may also beimplemented as consumer-electronic devices, such as smart glasses 112,smartwatch 114, digital camera 116, and media device 118, such as aset-top box as depicted, audio playback system, etc. Appliance 120 mayalso contain a computing system such as, for instance, anInternet-of-Things (IoT) node. Medical device 122 may contain anembedded computing platform. Likewise vehicle 124 may also contain oneor more computing platforms. Each computing platform may include aprocessor-based system, e.g., a machine capable of executinginstructions (sequential or otherwise) that specify actions to be takenby that machine.

FIG. 2 is a block diagram illustrating a computer system 200 in theexample form of a general-purpose machine. In certain embodiments,programming of the computer system 200 according to one or moreparticular algorithms produces a special-purpose machine upon executionof that programming. In a networked deployment, the computer system mayoperate in the capacity of either a server or a client machine inserver-client network environments, or it may act as a peer machine inpeer-to-peer (or distributed) network environments. As will be discussedin some examples below, a device may operate in a client mode or aserver mode in alternating fashion, depending on whether it is aninitiator, or responder, to a transaction or message.

Example computer system 200 includes at least one processor 202 (e.g., acentral processing unit (CPU), a graphics processing unit (GPU) or both,processor cores, compute nodes, etc.), a main memory 204 and a staticmemory 206, which communicate with each other via a link 208 (e.g.,bus). The computer system 200 may further include a video display unit210, an alphanumeric input device 212 (e.g., a keyboard), and a userinterface (UI) navigation device 214 (e.g., a mouse). The video displayunit, according to various embodiments, may include a complex,user-interactive display, or a simple numerical or alpha-numericaldisplay. In one embodiment, the video display unit 210, input device 212and UI navigation device 214 are incorporated into a touch screendisplay. The computer system 200 may additionally include a storagedevice 216 (e.g., a drive unit), a signal generation device 218 (e.g., aspeaker), a network interface device (NID) 220, and one or more sensors(not shown), such as a global positioning system (GPS) sensor, compass,accelerometer, or other sensor.

The storage device 216 includes a machine-readable medium 222 on whichis stored one or more sets of data structures and instructions 224(e.g., software) embodying or utilized by any one or more of themethodologies or functions described herein. The instructions 224 mayalso reside, completely or at least partially, within the main memory204, static memory 206, and/or within the processor 202 during executionthereof by the computer system 200, with the main memory 204, staticmemory 206, and the processor 202 also constituting machine-readablemedia.

While the machine-readable medium 222 is illustrated in an exampleembodiment to be a single medium, the term “machine-readable medium” mayinclude a single medium or multiple media (e.g., a centralized ordistributed database, and/or associated caches and servers) that storethe one or more instructions 224. The term “machine-readable medium”shall also be taken to include any tangible medium that is capable ofstoring, encoding or carrying instructions for execution by the machineand that cause the machine to perform any one or more of themethodologies of the present disclosure or that is capable of storing,encoding or carrying data structures utilized by or associated with suchinstructions. The term “machine-readable medium” shall accordingly betaken to include, but not be limited to, solid-state memories, andoptical and magnetic media. Specific examples of machine-readable mediainclude non-volatile memory, including but not limited to, by way ofexample, semiconductor memory devices (e.g., electrically programmableread-only memory (EPROM), electrically erasable programmable read-onlymemory (EEPROM)) and flash memory devices; magnetic disks such asinternal hard disks and removable disks; magneto-optical disks; andCD-ROM and DVD-ROM disks.

NID 220 according to various embodiments may take any suitable formfactor. In one such embodiment, NID 220 is in the form of a networkinterface card (NIC) that interfaces with processor 202 via link 208. Inone example, link 208 includes a PCI Express (PCIe) bus, including aslot into which the NIC form-factor may removably engage. In anotherembodiment, NID 220 is a network interface circuit laid out on amotherboard together with local link circuitry, processor interfacecircuitry, other input/output circuitry, memory circuitry, storagedevice and peripheral controller circuitry, and the like. In anotherembodiment, NID 220 is a peripheral that interfaces with link 208 via aperipheral input/output port such as a universal serial bus (USB) port.NID 220 transmits and receives data over transmission medium 226, whichmay be wired or wireless (e.g., radio frequency, infra-red or visiblelight spectra, etc.), fiber optics, or the like.

FIG. 3A is a diagram illustrating an exemplary hardware and softwarearchitecture of a computing device such as the one depicted in FIG. 2,in which various interfaces between hardware components and softwarecomponents are shown. As indicated by HW, hardware components arerepresented below the divider line, whereas software components denotedby SW reside above the divider line. On the hardware side, processingdevices 302 (which may include one or more microprocessors, digitalsignal processors, etc., each having one or more processor cores, areinterfaced with memory management device 304 and system interconnect306. Memory management device 304 provides mappings between virtualmemory used by processes being executed, and the physical memory. Memorymanagement device 304 may be an integral part of a central processingunit which also includes the processing devices 302.

Interconnect 306 includes a backplane such as memory, data, and controllines, as well as the interface with input/output devices, e.g., PCI,USB, etc. Memory 308 (e.g., dynamic random access memory—DRAM) andnon-volatile memory 309 such as flash memory (e.g.,electrically-erasable read-only memory—EEPROM, NAND Flash, NOR Flash,etc.) are interfaced with memory management device 304 and interconnect306 via memory controller 310. This architecture may support directmemory access (DMA) by peripherals in some embodiments. I/O devices,including video and audio adapters, non-volatile storage, externalperipheral links such as USB, Bluetooth, etc., as well as networkinterface devices such as those communicating via Wi-Fi or LTE-familyinterfaces, are collectively represented as I/O devices and networking312, which interface with interconnect 306 via corresponding I/Ocontrollers 314.

On the software side, a pre-operating system (pre-OS) environment 316,which is executed at initial system start-up and is responsible forinitiating the boot-up of the operating system. One traditional exampleof pre-OS environment 316 is a system basic input/output system (BIOS).In present-day systems, a unified extensible firmware interface (UEFI)is implemented. Pre-OS environment 316, is responsible for initiatingthe launching of the operating system, but also provides an executionenvironment for embedded applications according to certain aspects ofthe invention.

Operating system (OS) 318 provides a kernel that controls the hardwaredevices, manages memory access for programs in memory, coordinates tasksand facilitates multi-tasking, organizes data to be stored, assignsmemory space and other resources, loads program binary code into memory,initiates execution of the application program which then interacts withthe user and with hardware devices, and detects and responds to variousdefined interrupts. Also, operating system 318 provides device drivers,and a variety of common services such as those that facilitateinterfacing with peripherals and networking, that provide abstractionfor application programs so that the applications do not need to beresponsible for handling the details of such common operations.Operating system 318 additionally provides a graphical user interface(GUI) that facilitates interaction with the user via peripheral devicessuch as a monitor, keyboard, mouse, microphone, video camera,touchscreen, and the like.

Runtime system 320 implements portions of an execution model, includingsuch operations as putting parameters onto the stack before a functioncall, the behavior of disk input/output (I/O), and parallelexecution-related behaviors. Runtime system 320 may also perform supportservices such as type checking, debugging, or code generation andoptimization.

Libraries 322 include collections of program functions that providefurther abstraction for application programs. These include sharedlibraries, dynamic linked libraries (DLLs), for example. Libraries 322may be integral to the operating system 318, runtime system 320, or maybe added-on features, or even remotely-hosted. Libraries 322 define anapplication program interface (API) through which a variety of functioncalls may be made by application programs 324 to invoke the servicesprovided by the operating system 318. Application programs 324 are thoseprograms that perform useful tasks for users, beyond the tasks performedby lower-level system programs that coordinate the basis operability ofthe computing device itself.

FIG. 3B is a block diagram illustrating processing devices 302 accordingto some embodiments. In one embodiment, two or more of processingdevices 302 depicted are formed on a common semiconductor substrate. CPU340 may contain one or more processing cores 342, each of which has oneor more arithmetic logic units (ALU), instruction fetch unit,instruction decode unit, control unit, registers, data stack pointer,program counter, and other essential components according to theparticular architecture of the processor. As an illustrative example,CPU 340 may be a x86-type of processor. Processing devices 302 may alsoinclude a graphics processing unit (GPU) 344. In these embodiments, GPU344 may be a specialized co-processor that offloads certaincomputationally-intensive operations, particularly those associated withgraphics rendering, from CPU 340. Notably, CPU 340 and GPU 344 generallywork collaboratively, sharing access to memory resources, I/O channels,etc.

Processing devices 302 may also include caretaker processor 346 in someembodiments. Caretaker processor 346 generally does not participate inthe processing work to carry out software code as CPU 340 and GPU 344do. In some embodiments, caretaker processor 346 does not share memoryspace with CPU 340 and GPU 344, and is therefore not arranged to executeoperating system or application programs. Instead, caretaker processor346 may execute dedicated firmware that supports the technical workingsof CPU 340, GPU 344, and other components of the computer system. Insome embodiments, caretaker processor is implemented as amicrocontroller device, which may be physically present on the sameintegrated circuit die as CPU 340, or may be present on a distinctintegrated circuit die. Caretaker processor 346 may also include adedicated set of I/O facilities to enable it to communicate withexternal entities. In one type of embodiment, caretaker processor 346 isimplemented using a manageability engine (ME) or platform securityprocessor (PSP). Input/output (I/O) controller 348 coordinatesinformation flow between the various processing devices 340, 344, 346,as well as with external circuitry, such as a system interconnect.

FIG. 3C is a block diagram illustrating example components of CPU 340according to various embodiments. As depicted, CPU 340 includes one ormore cores 352, cache 354, and CPU controller 356, which coordinatesinteroperation and tasking of the core(s) 352, as well as providing aninterface to facilitate data flow between the various internalcomponents of CPU 340, and with external components such as a memory busor system interconnect. In one embodiment, all of the example componentsof CPU 340 are formed on a common semiconductor substrate.

CPU 340 includes non-volatile memory 358 (e.g., flash, EEPROM, etc.) forstoring certain portions of foundational code, such as an initializationengine, and microcode. Also, CPU 340 may be interfaced with an external(e.g., formed on a separate IC) non-volatile memory device 360 thatstores foundational code that is launched by the initialization engine,such as system BIOS or UEFI code.

Examples, as described herein, may include, or may operate on, logic ora number of components, circuits, modules, or engines, which for thesake of consistency are termed engines, although it will be understoodthat these terms may be used interchangeably. Engines may be hardware,software, or firmware communicatively coupled to one or more processorsin order to carry out the operations described herein. Engines may behardware engines, and as such engines may be considered tangibleentities capable of performing specified operations and may beconfigured or arranged in a certain manner. In an example, circuits maybe arranged (e.g., internally or with respect to external entities suchas other circuits) in a specified manner as an engine. In an example,the whole or part of one or more hardware processors may be configuredby firmware or software (e.g., instructions, an application portion, oran application) as an engine that operates to perform specifiedoperations. In an example, the software may reside on a machine-readablemedium. In an example, the software, when executed by the underlyinghardware of the engine, causes the hardware to perform the specifiedoperations. Accordingly, the term hardware engine is understood toencompass a tangible entity, be that an entity that is physicallyconstructed, specifically configured (e.g., hardwired), or temporarily(e.g., transitorily) configured (e.g., programmed) to operate in aspecified manner or to perform part or all of any operation describedherein.

Considering examples in which engines are temporarily configured, eachof the engines need not be instantiated at any one moment in time. Forexample, where the engines comprise a general-purpose hardware processorcore configured using software; the general-purpose hardware processorcore may be configured as respective different engines at differenttimes. Software may accordingly configure a hardware processor core, forexample, to constitute a particular engine at one instance of time andto constitute a different engine at a different instance of time.

According to various examples, an IoT devices are compliant withstandards promulgated by the Open Connectivity Foundation, such as theOpen Interconnect Consortium (OIC) Core Specification V1.1.1 (2016), forexample. The Core Specification documents specify the Framework, i.e.,the OCF core architecture, interfaces, protocols and services to enableOCF profiles implementation for IoT usages and ecosystems. As a generalprinciple, entities in the physical world (e.g., temperature sensor, anelectric light or a home appliance) are represented as resources.Interactions with an entity are achieved through its resourcerepresentations using operations that adhere to Representational StateTransfer (REST) architectural style, e.g., RESTful interactions.

The architecture defines the overall structure of the Framework as aninformation system and the interrelationships of the entities that makeup OCF. Entities are exposed as resources, with their unique identifiers(URIs) and support interfaces that enable RESTful operations on theresources. Every RESTful operation has an initiator of the operation(also referred to as the client role) and a responder to the operation(also referred to as the server role).

In the framework, the notion of the client and server is realizedthrough roles. Any device may act as a client and initiate a RESTfuloperation on any device acting as a server. Likewise, any device thatexposes entities as resources acts as a server. Conformant to the RESTarchitectural style, each RESTful operation contains all the informationto represent the context of the interaction and is driven using a smallset of generic operations, e.g., Create, Read, Update, Delete, Notify(CRUDN), which include representations of resources.

The architecture is organized conceptually into three major aspects thatprovide overall separation of concern: resource model, RESTfuloperations and abstractions. The resource model provides theabstractions and concepts to logically model, and logically operate onthe application and its environment. The core resource model is commonand agnostic to any specific application domain such as smart home,industrial or automotive. For example, the resource model defines aresource which abstracts an entity and the representation of a resourcemaps the entity's state. Other resource model concepts may be used tomodel other aspects, for example behavior. The generic CRUDN operationsare defined using the RESTful paradigm to model the interactions with aresource in a protocol and technology agnostic way.

The abstractions in the resource model and the RESTful operations aremapped to concrete elements using abstraction primitives. An entityhandler is used to map an entity to a resource and connectivityabstraction primitives are used to map logical RESTful operations todata connectivity protocols or technologies. Entity handlers may also beused to map resources to entities that are reached over protocols thatare not natively supported by OCF.

FIG. 4A is a diagram illustrating an example IoT device architectureaccording to some embodiments, at a high level of abstraction. Asillustrated, IoT device 400 includes communication facilities 402, coreresources 404, entity resource 406, and transaction resources 408.Communication facilities 402 include hardware, and instructionsexecutable on the hardware, that facilitate message exchange betweendevice 400 and a peer device. Communication facilities 402 may includewireless or wired networking architecture (e.g., WiFi, Long-termEvolution (LTE), personal-area networking (PAN) such as Bluetooth,home-area networking such as Zigbee, and the like, as well as wirednetworking architecture such as Ethernet, Fieldbus, or the like, alongwith corresponding firmware and software drivers to facilitate thehardware's operation).

Core resources 404 include a set of defined resources to enablefunctional interactions such as resource discovery, device management,GET operation, PUT operation, OBSERVE operation, and the like. Coreresources 404 may include a resource access manager that implementsvarious security policies such as firewall functionality.

Entity resources 406 represents one or more data sources or data sinks(e.g., data originators or data consumers) such as a data storagedevice, data capture device, computing platform, sensor, actuator, orthe like. In general, entity resources 406 include the operability thatis sought when device 400 is accessed. Entity resources 406 may alsoinclude an application that seeks to obtain information from, or sendinformation or commands to, an entity resource of a peer device.

According to some embodiments, transaction resources 408 includeresources to handle transactions in which sequences of multiple relatedmessages may be communicated to achieve a common objective or result,with one or more intermediate state changes taking place between theinitiation and conclusion of a given transaction. FIG. 4B illustrates anexample set of components that are included in transaction resources 408according to some embodiments. Transaction resources 408 include atransaction state machine 412 to represent the currentintra-transactional ephemeral state, a commit handler 414 to institute apersistent state change at the successful conclusion of a transaction,and a cleanup handler 416 to abort a transaction and clear out anypre-committed intermediate state changes in response to a transactionfailure. Also, transaction communicator 418 is included to conductintra-transaction communications with the transaction resources of apeer device.

In a related embodiment, transaction resources 408 include one or morediscoverable state graph data structures 420, discoverable by peerdevices, each of which represents the process flow of a correspondingtransaction type, including messages and allowed intra-transactionstates, which are supported by IoT device 400. In another relatedembodiment, transaction resources 408 include a collection 422 oftransaction message resources that are supported.

As an example, transaction resources 408 may include the followingproperties and attributes:

-   Resource Attributes    -   Resource Type: “rt”=“ocf.tx.<tx_name>    -   Discoverable: YES—allows a peer device to initiate transaction    -   Interfaces: “baseline”13 CR-N (observe)-   Resource Properties    -   “txs”—current state of the transaction    -   “txg”—graph defining reachable states and transitions    -   “txi”—Tx instance identifier    -   “txh”—hash of Tx messages exchanged    -   “txc”—Collection resource with references to transaction message        resources.

In an example, intra-transaction state changes are achieved through theexchange of RESTful messages between one or more peer devices. Messageencoding may vary for the various states defined in a given transaction.Hence, it is possible for an IoT core layer to optimize message delivery(e.g., mixing multiple messaging models such as request/response,pub/sub, event/notify etc.) without impacting the transaction resourcesor the logic contained in the transaction communicator.

FIG. 5 is a diagram illustrating an example state graph data structures420 according to an embodiment. As depicted, start states may includeinitiation INIT and response RESP states. Protocol states to carry out atransaction may include messages MSG-A-MSG-X as shown. Error statesinclude RESTART and ABORT states, and a success state includes DONE.

To ensure progress is achieved the protocol state dependencies arenon-circular in this example. The responder may observe the stateproperty of the Initiator's Tx resource specifying the state value(s)that trigger notification responses. For instance, observing the MSG-Bstate subsequent to posting a MSG-A message would allow the Responder totake an extended period of time processing MSG-A. The initiator mayreturn to doing other tasks, or going to sleep, knowing that when theresponder is ready to post MSG-B it will receive a notification to wakeup or listen for activity from the Responder.

Notifications may also be used to signal when it is appropriate to freecomputing resources allocated to perform the transaction. For example,DONE or ABORT notification might cause the device to free memory used tocontain message buffers and temporary files. Whatever the reason forobservation of a state property, the transaction communicator may ensurea valid sequence of messages is processed.

FIG. 6 is a diagram illustrating transaction message collection 422according to an example. As depicted, the transaction resource TX RSRCcontains a collection property comprising a list of message resourcesMSG-A_RSRC=MSG-C_RSRC that describe the objects to be exchanged duringthe course of the transaction.

FIG. 7 is a block diagram illustrating the transaction resources of anIoT device according to an embodiment utilizing an IoT framework such asOCF/IoTivity. In this example, device 700 is shown with transactionresources provisions for initiator role 702, and for responder role 704.As described above, the initiator and responder roles may be performedby the same device, often times in alternating fashion, duringtransaction communications and message processing. To carry outinitiator role 702, transaction communicator 706 is provided.Transaction communicator 706 performs posting of messages directed tothe transaction communicator of a peer device (which would be configuredas a responder role to receive the posted messages). Transactioncommunicator 706 is informed by state graph 710, which represents theproper sequence of states throughout the course of the transaction, andtransaction state machine 712, which represents the current state. Thestate graph 710 indicates the action (e.g., message type) to be sent bytransaction communicator 706; whereas transaction state machine 712indicates when, or whether, the action is to be taken.

Also instantiated in the responder role 704 are transaction messagecollection 708, which contains the set of messages associated with thetransactions supported by device 700, cleanup handler 716, and commithandler 718. The transaction resources of responder role 704 receive andrespond to various messages. In the example depicted, DISCOVER, OBSERVE,PUT, and POST messages may be received and processed. As shown, device700 may be externally programmed to operate in its initiator role tostart a transaction.

The transaction resources access entity 720 may include sensor 722,actuator 724, and data store 726. As illustrated, the transactionresources access the resources of entity 720 via commit handler 718,which exercises the responsibility of calling for a persistent statechange of device 700.

FIG. 8 is a flow diagram illustrating the progress of an exampletransaction between two IoT devices, each utilizing its respectivetransaction resources. As depicted, the initiator device has transactionresources 802, and the responder device has transaction resources 804which correspond to transaction resources 802. In this example, the factthat the initiator and responder devices have matching transactionresources is a precondition for their ability to carry out thetransaction. In a related embodiment, the initiator device may havepreviously used a supported discovery or inquiry protocol to checkwhether the responder device possesses the resources needed for thetransaction.

The transaction starts with the initiator device posting the message Aresource MSG-A RSRC at 806. The responder responds with a response codeRESP CODE, and processes message A at 808. At 810, the responder postsmessage B, to which the initiator responds with a response code RESPCODE. At 812, the initiator devices processes message B. Thereafter, inaccordance with the transaction's predefined protocol, the initiatorposts message C at 814, to which the responder device responds with theresponse code, and processes received message C at 816.

Messages A-C in this example are RESTful message exchanges controlled bya state property that ensures the transaction progresses in a predefinedway. The response codes sent by each recipient of a message in turn areindicative of the forward progress of the transaction protocol. In theabsence of receipt of a response code, the transmitting device may retryafter a period of time, or abort the transaction after some number ofretry failures, for example.

Once processing of message C is complete, the responder device mayperform an OBSERVE operation at 818 to check for the completion state,DONE. The initiator device in this case provides a DONE statenotification observable by the responder device. In response to thesuccessful completion of the transaction, each device may update itspersistent state to reflect completion of the transaction. Accordingly,at 822, the responder device commits the transaction by updating itspersistent state. Likewise, at 824, the initiator device commits thetransaction by updating its persistent state accordingly. In the eventof a failure of the transaction, no persistent state change is made ineither device.

FIG. 9 is a system architecture and data flow diagram illustratingexample interactivity between a pair of IoT devices utilizing principlesof some embodiments. Device A 900 and Device B 920 are respectivelyconfigured with entity resources ER1 902 and ER2 922, and transactionresources TR1 and TR2, including respective transaction state machines904 and 924, transaction state graphs 906 and 926, and transactioncommunicators 908 and 928. Core resources of the devices includeresource access manager 910 for device A 900, and resource accessmanager 930 for device B 920. Each device also includes communicationsfacilities, as indicated respectively at 912 and 932. In the exampleillustrated, device B 920 also includes application 918, which in thefollowing operational use case initiates a transaction to access entityresource ER1 902.

As indicated, resource access manager 910 includes an access controlentry that denies direct access to entity resource ER1 902 from device B920, but allows device B 920 to access transaction resources TR1.Accordingly, in operation, interaction A directed from application 918to entity resource ER1 902 is blocked by resource access manager 910.

However, interaction B, originating at application 918 and directed totransaction resources TR1 of device A 900, is permitted by resourceaccess manager 910. Interaction B may be a DISCOVER request, forinstance, that explores whether device A 900 or, more particularly,whether transaction resources TR1 contain a matching transactionconfiguration (e.g., message collection, state graph) to the transactionintended by device B. In response to device A having a suitable set oftransaction resources, transaction resources TR1 and TR2, viatransaction communicators 908 and 928 respectively, exchange messagesaccording to TX state graphs 906 and 926. Transaction state machines 904and 924 advance through their configured finite-state automata ininteractions C and D, which may include different messages in theappropriate sequence. Transaction state machines 904 and 924 maintainephemeral states within the confines of the current transaction. At thesuccessful conclusion of the transaction, the entity resource ER1 902 isupdated at E to institute a persistent state change to commit thetransaction. If the transaction were to fail, no persistent state changeat E would be instituted.

According to another embodiment, multiple IoT devices with transactionresources are configured to implement a workflow process that hasdistributed sequencing control. A workflow process orchestration engineconfigured as part of the transaction resources describes a workflowprocess model, and then partitions the model according to the respectivenode devices such that the workflow operations between any two workflowneighbors forms a transaction. A workflow node maintains two instancesof a transaction resource such that the results of an A-to-B transactionmay feed a B-to-C transaction, for example.

According to a related embodiment, the transaction resource includes atemplate that defines a second resource as a derived type of thetransaction resource such that a resource type of the second resource iscontained in the resource type value of the transaction resource. Forexample if the transaction resource has a type designation of“rt”=“ocf.r.tx” then a second derived resource (dr) type may bedesignated by “rt”=“ocf.r.tx.dr”.

In an example, the semantics of template derivation are such that allthe properties defined by the template are available to the derivedresource as if they were originally defined by the derived resource.This approach may differ from a first resource referencing a secondresource in that the realization of a template resource has a singleresource instance, whereas a first resource referencing a secondresource will have two resource instances.

Resource template semantics may further be defined to have propertyoverloading such that if a derived resource defines a property named thesame as a property named by the template resource. The data structuredefined by the template may be hidden from the initiator device seekingto introspect the derived resource. Nevertheless, the derived resourcemay reference the template defined property using a localized reference.(E.g. if the template resource defines a property “tx1” and the derivedresource also defines a property “tx1” a local reference may beconstructed using name mangling such that the resource name ispre-pended to the property name; e.g., “tx_tx1”. The mangled propertyhas CRUDN permissions of “-----” such that only local references may beconstructed, for instance.

Advantageously, in overloading of the property name the temporality ofthe property may be variable. This may allow the hidden property valueto remain unchanged (e.g., its state may persist while a new state isbeing negotiated by the transaction protocol). When the protocolcommits, or rolls-back the new state may be established quickly. Thisfacilitates safer operation.

Property overloading also offers certain security and privacy benefitswhere a sensitive property value may be hidden during an exchange thatmay result in a decision not to disclose the hidden property value.Hence, the sensitive value is not at risk of disclosure during thenegotiation phase. A security policy may require substitution with aless sensitive value until the FSA commits.

ADDITIONAL NOTES & EXAMPLES

Example 1 is a communications device, comprising: a computing platform,including a processor, a data store, and communication facilities; anentity resource to originate or consume data; core resources tofacilitate stateless messaging with a remote device associated with theentity resource; and transaction resources to manage a transaction withthe remote device that includes a sequence of messages associated withthe entity resource, including: a transaction state machine to representa current intra-transactional ephemeral state from among a plurality ofintra-transactional ephemeral states representing progression of thetransaction; a commit handler to institute a persistent state changerelated to the entity resource in response to a successful completion ofthe transaction; and a transaction communicator to conductintra-transaction communications via the core resources directed tocorresponding transactional resources of the remote device.

In Example 2, the subject matter of Example 1 optionally includeswherein the device is an Internet-of-Things (IoT) device.

In Example 3, the subject matter of any one or more of Examples 1-2optionally include

In Example 4, the subject matter of any one or more of Examples 1-3optionally include wherein the stateless messaging includes RESTfulmessaging.

In Example 5, the subject matter of any one or more of Examples 1-4optionally include a cleanup handler to abort the transaction and removeany remaining ephemeral state indicia in response to a failure of thetransaction.

In Example 6, the subject matter of any one or more of Examples 1-5optionally include wherein the core resources include a set of definedresources to enable functional interactions selected from the groupconsisting of: resource discovery, device management, GET operation, PUToperation, OBSERVE operation, or any combination thereof.

In Example 7, the subject matter of any one or more of Examples 1-6optionally include wherein the core resources include a resource accessmanager to implement security a policy that limits direct access to theentity resource but permits access to the entity resource via thetransaction resources.

In Example 8, the subject matter of any one or more of Examples 1-7optionally include wherein the transaction resources include a stategraph data structure that represents a process flow of the transactionas a sequence of the ephemeral states.

In Example 9, the subject matter of Example 8 optionally includeswherein the state graph data structure is discoverable by the remotedevice.

In Example 10, the subject matter of any one or more of Examples 1-9optionally include wherein the transaction resources include acollection resource that represents transaction message resourcesassociated with the transaction.

In Example 11, the subject matter of Example 10 optionally includeswherein the collection resource is discoverable by the remote device.

In Example 12, the subject matter of any one or more of Examples 1-11optionally include wherein the entity resource includes an applicationresource to initiate the transaction and to undergo a persistent statechange in response to successful completion of the transaction.

In Example 13, the subject matter of any one or more of Examples 1-12optionally include wherein the entity resource includes at least onedata source selected from the group consisting of: a sensor, anactuator, a data store.

Example 14 is a method for operating a communications device, the methodcomprising: interfacing with an entity resource that originates orconsumes data; communicating stateless messaging with a remote device,the stateless messaging being associated with the entity resource; andmanaging a transaction with the remote device, the transaction includinga sequence of messages associated with the entity resource, wherein themanaging of the transaction includes: representing a currentintra-transactional ephemeral state from among a plurality ofintra-transactional ephemeral states representing progression of thetransaction; instituting a persistent state change related to the entityresource in response to a successful completion of the transaction; andconducting intra-transaction communications via the core resourcesdirected to corresponding transactional resources of the remote device.

In Example 15, the subject matter of Example 14 optionally includeswherein the communications device is an Internet-of-Things (IoT) device.

In Example 16, the subject matter of any one or more of Examples 14-15optionally include

In Example 17, the subject matter of any one or more of Examples 14-16optionally include wherein the stateless messaging includes RESTfulmessaging.

In Example 18, the subject matter of any one or more of Examples 14-17optionally include aborting the transaction and removing any remainingephemeral state indicia in response to a failure of the transaction.

In Example 19, the subject matter of any one or more of Examples 14-18optionally include wherein the stateless messaging facilitatesfunctional interactions selected from the group consisting of: resourcediscovery, device management, GET operation, PUT operation, OBSERVEoperation, or any combination thereof

In Example 20, the subject matter of any one or more of Examples 14-19optionally include implementing a security a policy that limits directaccess to the entity resource but permits access to the entity resourcevia the transaction resources.

In Example 21, the subject matter of any one or more of Examples 14-20optionally include wherein managing the transaction includes storing astate graph data structure that represents a process flow of thetransaction as a sequence of the ephemeral states.

In Example 22, the subject matter of Example 21 optionally includeswherein the state graph data structure is discoverable by the remotedevice.

In Example 23, the subject matter of any one or more of Examples 14-22optionally include wherein managing the transaction includes storing acollection resource that represents transaction message resourcesassociated with the transaction.

In Example 24, the subject matter of Example 23 optionally includeswherein the collection resource is discoverable by the remote device.

In Example 25, the subject matter of any one or more of Examples 14-24optionally include wherein the entity resource includes an applicationresource to initiate the transaction and to undergo a persistent statechange in response to successful completion of the transaction.

In Example 26, the subject matter of any one or more of Examples 14-25optionally include wherein the entity resource includes at least onedata source selected from the group consisting of: a sensor, anactuator, a data store.

Example 27 is at least one machine-readable medium containinginstructions that, when executed on a communications device, cause thecommunications device to carry out the method according to any one ofExamples 14-27.

Example 28 is a communications system device comprising means forcarrying out the method according to any one of Examples 14-27.

Example 29 is at least one machine-readable medium comprisinginstructions that, when executed on a computing platform of acommunications device, cause the communications device to performoperations including: interfacing with an entity resource thatoriginates or consumes data; communicating stateless messaging with aremote device, the stateless messaging being associated with the entityresource; and managing a transaction with the remote device, thetransaction including a sequence of messages associated with the entityresource, wherein the managing of the transaction includes: representinga current intra-transactional ephemeral state from among a plurality ofintra-transactional ephemeral states representing progression of thetransaction; instituting a persistent state change related to the entityresource in response to a successful completion of the transaction; andconducting intra-transaction communications via the core resourcesdirected to corresponding transactional resources of the remote device.

In Example 30, the subject matter of Example 29 optionally includeswherein the communications device is an Internet-of-Things (IoT) device.

In Example 31, the subject matter of any one or more of Examples 29-30optionally include

In Example 32, the subject matter of any one or more of Examples 29-31optionally include wherein the stateless messaging includes RESTfulmessaging.

In Example 33, the subject matter of any one or more of Examples 29-32optionally include instructions for causing the communications device toabort the transaction and remove any remaining ephemeral state indiciain response to a failure of the transaction.

In Example 34, the subject matter of any one or more of Examples 29-33optionally include wherein the stateless messaging facilitatesfunctional interactions selected from the group consisting of: resourcediscovery, device management, GET operation, PUT operation, OBSERVEoperation, or any combination thereof.

In Example 35, the subject matter of any one or more of Examples 29-34optionally include instructions for implementing a security a policythat limits direct access to the entity resource but permits access tothe entity resource via the transaction resources.

In Example 36, the subject matter of any one or more of Examples 29-35optionally include wherein managing the transaction includes storing astate graph data structure that represents a process flow of thetransaction as a sequence of the ephemeral states.

In Example 37, the subject matter of Example 36 optionally includeswherein the state graph data structure is discoverable by the remotedevice.

In Example 38, the subject matter of any one or more of Examples 29-37optionally include wherein managing the transaction includes storing acollection resource that represents transaction message resourcesassociated with the transaction.

In Example 39, the subject matter of Example 38 optionally includeswherein the collection resource is discoverable by the remote device.

In Example 40, the subject matter of any one or more of Examples 29-39optionally include wherein the entity resource includes an applicationresource to initiate the transaction and to undergo a persistent statechange in response to successful completion of the transaction.

In Example 41, the subject matter of any one or more of Examples 29-40optionally include wherein the entity resource includes at least onedata source selected from the group consisting of: a sensor, anactuator, a data store.

Example 42 is a system for a communications device, the systemcomprising: means for interfacing with an entity resource thatoriginates or consumes data; means for communicating stateless messagingwith a remote device, the stateless messaging being associated with theentity resource; and means for managing a transaction with the remotedevice, the transaction including a sequence of messages associated withthe entity resource, wherein the means for managing of the transactioninclude: means for representing a current intra-transactional ephemeralstate from among a plurality of intra-transactional ephemeral statesrepresenting progression of the transaction; means for instituting apersistent state change related to the entity resource in response to asuccessful completion of the transaction; and means for conductingintra-transaction communications via the core resources directed tocorresponding transactional resources of the remote device.

In Example 43, the subject matter of Example 42 optionally includeswherein the communications device is an Internet-of-Things (IoT) device.

In Example 44, the subject matter of any one or more of Examples 42-43optionally include

In Example 45, the subject matter of any one or more of Examples 42-44optionally include wherein the stateless messaging includes RESTfulmessaging.

In Example 46, the subject matter of any one or more of Examples 42-45optionally include means for aborting the transaction and removing anyremaining ephemeral state indicia in response to a failure of thetransaction.

In Example 47, the subject matter of any one or more of Examples 42-46optionally include wherein the stateless messaging facilitatesfunctional interactions selected from the group consisting of: resourcediscovery, device management, GET operation, PUT operation, OBSERVEoperation, or any combination thereof.

In Example 48, the subject matter of any one or more of Examples 42-47optionally include means for implementing a security a policy thatlimits direct access to the entity resource but permits access to theentity resource via the transaction resources.

In Example 49, the subject matter of any one or more of Examples 42-48optionally include wherein the means for managing the transactioninclude means for storing a state graph data structure that represents aprocess flow of the transaction as a sequence of the ephemeral states.

In Example 50, the subject matter of Example 49 optionally includeswherein the state graph data structure is discoverable by the remotedevice.

In Example 51, the subject matter of any one or more of Examples 42-50optionally include wherein the means for managing the transactioninclude means for storing a collection resource that representstransaction message resources associated with the transaction.

In Example 52, the subject matter of Example 51 optionally includeswherein the collection resource is discoverable by the remote device.

In Example 53, the subject matter of any one or more of Examples 42-52optionally include wherein the entity resource includes an applicationresource to initiate the transaction and to undergo a persistent statechange in response to successful completion of the transaction.

In Example 54, the subject matter of any one or more of Examples 42-53optionally include wherein the entity resource includes at least onedata source selected from the group consisting of: a sensor, anactuator, a data store.

The above detailed description includes references to the accompanyingdrawings, which form a part of the detailed description. The drawingsshow, by way of illustration, specific embodiments that may bepracticed. These embodiments are also referred to herein as “examples.”Such examples may include elements in addition to those shown ordescribed. However, also contemplated are examples that include theelements shown or described. Moreover, also contemplated are examplesusing any combination or permutation of those elements shown ordescribed (or one or more aspects thereof), either with respect to aparticular example (or one or more aspects thereof), or with respect toother examples (or one or more aspects thereof) shown or describedherein.

Publications, patents, and patent documents referred to in this documentare incorporated by reference herein in their entirety, as thoughindividually incorporated by reference. In the event of inconsistentusages between this document and those documents so incorporated byreference, the usage in the incorporated reference(s) are supplementaryto that of this document; for irreconcilable inconsistencies, the usagein this document controls.

In this document, the terms “a” or “an” are used, as is common in patentdocuments, to include one or more than one, independent of any otherinstances or usages of “at least one” or “one or more.” In thisdocument, the term “or” is used to refer to a nonexclusive or, such that“A or B” includes “A but not B,” “B but not A,” and “A and B,” unlessotherwise indicated. In the appended claims, the terms “including” and“in which” are used as the plain-English equivalents of the respectiveterms “comprising” and “wherein.” Also, in the following claims, theterms “including” and “comprising” are open-ended, that is, a system,device, article, or process that includes elements in addition to thoselisted after such a term in a claim are still deemed to fall within thescope of that claim. Moreover, in the following claims, the terms“first,” “second,” and “third,” etc. are used merely as labels, and arenot intended to suggest a numerical order for their objects.

The above description is intended to be illustrative, and notrestrictive. For example, the above-described examples (or one or moreaspects thereof) may be used in combination with others. Otherembodiments may be used, such as by one of ordinary skill in the artupon reviewing the above description. The Abstract is to allow thereader to quickly ascertain the nature of the technical disclosure. Itis submitted with the understanding that it will not be used tointerpret or limit the scope or meaning of the claims. Also, in theabove Detailed Description, various features may be grouped together tostreamline the disclosure. However, the claims may not set forth everyfeature disclosed herein as embodiments may feature a subset of saidfeatures. Further, embodiments may include fewer features than thosedisclosed in a particular example. Thus, the following claims are herebyincorporated into the Detailed Description, with a claim standing on itsown as a separate embodiment. The scope of the embodiments disclosedherein is to be determined with reference to the appended claims, alongwith the full scope of equivalents to which such claims are entitled.

What is claimed is:
 1. A communications device, comprising: a computingplatform, including a processor, a data store, and communicationfacilities, the computing platform to implement: an entity resource tooriginate or consume data; core resources to facilitate statelessmessaging with a remote device associated with the entity resource; andtransaction resources to manage a transaction with the remote devicethat includes a sequence of messages associated with the entityresource, the transaction resources including: a transaction statemachine to represent a current intra-transactional ephemeral state fromamong a plurality of intra-transactional ephemeral states representingprogression of the transaction; a commit handler to institute apersistent state change related to the entity resource in response to asuccessful completion of the transaction; and a transaction communicatorto conduct intra-transaction communications via the core resourcesdirected to corresponding transactional resources of the remote device.